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Abstract 

We present a new model format for automatized matrix-element generators, the so- 
called Universal FeynRules Output (UFO). The format is universal in the sense that 
it features compatibility with more than one single generator and is designed to be 
flexible, modular and agnostic of any assumption such as the number of particles or 
the color and Lorentz structures appearing in the interaction vertices. Unlike other 
model formats where text files need to be parsed, the information on the model is 
encoded into a Python module that can easily be linked to other computer codes. 
We then describe an interface for the Mathematica package FeynRules that 
allows for an automatic output of models in the UFO format. 

Key words: Model building, model implementation, Feynman rules, Feynman 
diagram calculators, Monte Carlo programs. 
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1 Introduction 



Monte Carlo simulations of the physics to be observed at the Large Hadron 
Collider (LHC) at CERN play a central role in the exploration of the elec- 
troweak scale, both from the experimental point of view of establishing an 
excesses over the expected Standard Model (SM) backgrounds as well as from 
the phenomenological point of view by providing possible explanations for the 
observations. For this reason, activities in the field of Monte Carlo simula- 
tions have been rather intense over the last fifteen years, resulting in many 
advances in the field. Automated tree-level matrix-element generators, such as 
Alpgen [JJ, Comix [2], CompHep/CalcHep [3Pf5] . Helac [6], Herwig 
[7118] . MadGraph/MadEvent pfT0lfTTlT2lT3] . Sherpa [TlfTo] . or Whizard 
[TBITT] . describing the hard scattering processes where the Beyond the Stan- 
dard Model (BSM) physics is expected to show up have been developed. As 
a consequence, the problem of the automatic generation of tree-level matrix 
elements for a large class of Lagrangian-based BSM theories is solved, at least 
in principle. 

Due to the numerous existing BSM theories based on ideas in constant evo- 
lution, the implementation of these models into Monte Carlo event genera- 
tors remains a tedious and error-prone task. Feynman rules associated with 
a given BSM model must be derived and then implemented one at the time 
into the various codes, which often follow their own specific conventions and 
formats. A first step in the direction of automating this procedure by starting 
directly from the Lagrangian of the model has been made in the context of 
the LanHep package [18] linked to the CompHep and CalcHep programs. 
Recently, a new efficient framework going beyond this scheme has been de- 
veloped. It is based on the FeynRules package fT§l2U[21|l2"2"] and proposes a 
general and flexible environment allowing to develop a model, investigate its 
phenomenology and eventually confront it to data. Its virtue has been illus- 
trated in the context of the CompHep/CalcHep, FeynArts/FormCalc 
[23] . MadGraph/MadEvent, Sherpa and Whizard programs, by imple- 
menting several new physics theories in FeynRules and then passing them 
to the different tools for a systematic validation procedure. The approach is 
based on a modular structure where each node consists in an interface to a ded- 
icated matrix-element generator. Since the latter have in general hard-coded 
information regarding the supported Lorentz and/or color structures, the in- 
terfaces check whether a given vertex is compliant with a given matrix-element 
generator, in which case the vertex is written to file in a format suitable for 
the generator. The final output consists then in a set of text files that can be 
used in a similar way to any other built-in model. 

The procedure spelled out above, where communication between FeynRules 
and the matrix-element generators proceeds exclusively via a set of well- 
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defined text files that must be parsed and interpreted, has some serious limita- 
tions. In particular, extending the format to include more general structures, 
like higher- dimensional operators and/or non-standard color structures, is dif- 
ficult to incorporate into a static text-based format. In this paper we present 
a new format, dubbed the Universal FeynRules Output or the UFO, for 
model files that goes beyond existing formats in various ways. The format 
is completely generic and, unlike existing formats, it does not make any a 
priori assumptions on the structures that can appear in a model. The aim 
is to provide a flexible format, where all the information about a model is 
represented in an abstract form that can easily be accessed by other tools. 
The information on the particles, parameters and vertices of the model are 
stored in a set of Python objects, each of them being associated with a list 
of attributes related to their properties. This way of representing the model 
information has some benefits over the more traditional plain text table-based 
format, because it allows, e.g., to add a missing piece of information directly as 
a new attribute to an existing object. As an example, extending a table-based 
format to accommodate higher-point vertices requires to change the format 
of the table and to adapt the readers for the table accordingly. In an object- 
oriented format like the UFO, the same extension is trivial, as the number of 
particles entering a vertex is just an attribute of the vertex, so no extension 
of rewriting of the readers is necessary. Presently, the UFO format is already 
used by the MadGraph version 5 [13] and the GoSam generators [2"3|25|26| . 
and will be used in a near future by HERWIG++. 

The paper is organized as follows. In Section [2l we describe the features of 
the UFO format as a stand-alone Python module, while Section [3] addresses 
the automation of writing an UFO model through FeynRules. Section H] is 
dedicated to the UFO features beyond tree level and in Section [5l we provide 
an example of how to implement a model containing non-trivial Lorentz struc- 
tures with the help of FeynRules into MadGraph 5. Our conclusions are 
drawn in Section [HI 



2 The UFO format 

Any quantum field theory can be defined by a threefold information, 

• a set of particles, defined together with their quantum numbers (spin, elec- 
tric charge, etc.), 

• a set of parameters (masses, coupling constants, etc, ...), 

• a Lagrangian describing the interactions among the different particle species. 

However, matrix-element generators do not work, in general, directly with 
the Lagrangian, but rather with an explicit set of vertices. In the rest of this 
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section, we assume that we have extracted all the vertices from the Lagrangian 
of a given model and only restrict ourselves to describing a new generic format 
to implement the information on the particles and parameters of the model 
along with the vertices describing the interactions among the particles into 
matrix-element generators. The issue of the extraction of the vertices from 
the Lagrangian and their translation into this new format in an automated 
fashion via the FeynRules package will be discussed in Section [3j 

The Universal FeynRules Output (UFO) allows to translate all the infor- 
mation about a given particle physics model into a Python module that 
can easily be linked to existing matrix-element generators. While in general 
each generator is following its own format and conventions, the UFO format 
goes beyond this approach in the sense that it is, by definition, not tied to 
any specific matrix-element generator. More specifically, it saves the model 
information in an abstract (generator-independent) way in terms of PYTHON 
objects. An UFO model is hence a standalone Python module, containing 
ready-to-go definitions for all the classes representing particles, parameters, 
etc., and which can be directly linked to an existing matrix-element generator 
without any modification or further interfacing. 

In this section we give a detailed account on the UFO format, putting special 
emphasis on the definition of the different classes useful for designing model 
files. In general, an UFO model consists of a directory containing a set of text 
files that can be split into two distinct classes, 

• Model-independent files: 

- __init__.py, 

- object_library .py, 

- function_library .py, 

- write_param_card.py, 

• Model-dependent files: 

- particles .py, 

- parameters .py, 

- vertices. py, 

- couplings .py, 

- lorentz.py, 

- coupling_orders .py. 

Since the UFO format is based on the Python language, all files have a .py 
extension. The model-independent files are identical for every model and con- 
tain, among others, the definitions of the classes which the model-dependent 
objects (particles, parameters, etc.) are instances of. All those files are pro- 
vided as self-contained Python modules. 
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2.1 Initialization and structure of the objects and functions 

A file named init .py inside a directory is standard in the PYTHON 

language and corresponds to a tag for importing complete Python modules 
by issuing the Python command 

import Directory_Name 

where Directory_Name refers to the name of the directory containing the 
init .py file. However, in addition to the possiblity of importing a com- 
plete UFO model, this file also contains, in the UFO case, links to different 
lists of quantities associated with the various objects defined in a model, 

• all_particles 

• all_vertices 

• all_couplings 

• all_lorentz 

• all_parameters 

• all_coupling_orders 

• all_f unctions 

These lists allow, e.g., to access the full particle content of a model in an easy 
way downstream in the code. Moreover, every time that an instance of a class 
is created in the model, it will be automatically added to the corresponding 
list. 

An UFO model can be fully implemented with the help of a small number 
of basic classes, denoted Particle, Parameter, Vertex, Coupling, Lorentz 
and CouplingOrder. All of these classes are derived from the mother class 
UFOBaseClass, defining a set of common methods and attributes accessible in 
the same way by each class. The mother class, together with all its children, is 
defined in the file object_library .py. In particular, each class has methods 
to display all the attributes associated to a given instance of the class, as 
well as to return or set the values of these attributes. As an example, if P is 
an instance of the class Particle and if charge is an attribute of this class 
(see Section |2^2|) . the charge of the corresponding particle can be accessed in 
the standard way by issuing the command P. charge. The complete list of 
attributes of the UFOBaseClass class is summarized in Table [U 

The file function_library .py is related to the implementation of user-defined 
functions into an UFO module via the special class Function, which translates 
functions that can be defined within a single Python line (i.e., the so-called 
Python 'lambda' functions) to other programming languages (such as For- 
tran or C++). Let us note that this specific type of functions is currently 
the only type of user-defined functions supported by the UFO format. A mem- 
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Table [TJ Attributes and methods available to all UFO classes 


get_all 


Returns a list of all the attributes of an object. 


nice_string 


Returns a string with a representation of an object contain- 
ing the values associated with each of its attributes. 


get 


This method provides access to the value of an attribute 
of an object. As an example, if P denotes an instance of 
a class with attribute charge, then P . get ( ' charge ' ) and 
P . charge are equivalent means of accessing the value of the 
attribute charge. 


set 


This method allows one to modify the value of an attribute 
of an object. As an example, if P denotes an instance of 
class with attribute charge, then P . set ( ' charge ' , 1) , or 
equivalently P . charge = 1 , will set the attribute denoted 
by charge to unity. 



ber of the class Function contains three mandatory attributes, called name, 
arguments and expression. While name is a string representing the name 
of the function, the attributes arguments and expression correspond to a 
sequence of strings for the names of the variables the function depends upon 
and a string representing the valid Python expression defining the function 
itself. Several functions are by default included into the UFO function library, 

• complexconjugate: complex conjugation, 

• esc: the trigonometric function cosecant, 

• acsc: the cyclometric function arccosecant, 

• im: the imaginary part of a complex number, 

• re: the real part of a complex number, 

• sec: the trigonometric function secant, 

• asec: the cyclometric function arcsecant. 

These functions consist in a set of common mathematical functions for which 
the standard Python module cmath is insufficient or unpractical. As an ex- 
ample, the cosecant function esc (not included in the cmath library) is im- 
plemented within the UFO module as an instance of the aforementioned class 
Function via 

esc = Function(name = 'esc', 

arguments = ('z',), 

expression = ' 1 . /cmath. sin (z) ' ) 
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2.2 Implementation of the particle content of a model 

In the UFO format, all particles are instances of the class Particle defined in 
the file particles .py. Even if the Lagrangian of a model is in general more 
easily written in terms gauge eigenstates, matrix-element generators usually 
work at the level of mass eigenstates. Hence only mass eigenstates should be 
defined in the particles.py file. 

The definition of a particle might read, for, e.g., a top quark, as 

t = Particle ( pdg_code = 6, 
name = ' t ' , 
antiname = 't~ ' , 
spin = 2, 
color = 3, 
mass = Param.MT, 
width = Param.WT, 
texname = ' t ' , 
antitexname = '\\bar{t}', 
charge = 2/3, 
line = 'straight', 
LeptonNumber = 
) 

The class Particle has various attributes that are summarized in Table [2j In 
the following we content ourselves to highlight only the most important points. 
First, note that, apart from a set of mandatory arguments (all attributes but 
the last two in the example above), the Particle class can be given an arbi- 
trary number of optional attributes (the line and LeptonNumber attributes in 
the example). There are three predefined optional attributes, which are sum- 
marized in Table [2j Every additional optional attribute must be an integer 
representing additional model-dependent additive quantum numbers (as the 
attribute LeptonNumber in the example). The only exceptions regarding the 
treatment of the quantum numbers concern the electric charge and color rep- 
resentation, which are always mandatory and stored in the attributes charge 
and color. 

A particle object is identified through its name, a string stored in the name 
attribute. In a similar fashion, the attribute antiname is a string representing 
the name of the corresponding antiparticle. Note that self-conjugate particles, 
i.e., particles that are their own antiparticles, are identified by having identi- 
cal name and antiname attributes {i.e., even for self-conjugate particles, the 
antiname attribute must be defined). The transformation properties of the 
particle under the Lorentz group and the QCD and electromagnetic gauge 
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groups are specified through the spin, color and charge attributes. Each of 
these attributes takes an integer value: 

• spin: the possible values are 2s + 1, where s is the spin of the particle. For 
the moment only s < 2 is supported. By convention, the value —1 is used 
for ghost fields. 

• color: the possible values are 1, ±3, ±6 and 8, corresponding to singlets, 
(anti)triplets, (anti)sextets and octets. 

• charge: any rational number, representing the electric charge of the particle. 

Inside matrix-element generators, particles are often identified through an 
integer number referring to the Particle Data Group (PDG) numbering scheme 
[27]. This code is stored in the pdg_code attribute, which can be set to any 
integer value, even though it is highly recommended to follow the existing 
conventions whenever possible. Finally, masses and widths are encoded in the 
mass and width attributes. They refer to the corresponding instances of the 
Parameter class defined in the file parameters .py (see Section |2~3|) . Therefore, 
at the beginning of the particles . py file, the Parameter objects are imported 
via the Python instruction 

import parameters as Param 

In the previous example we have only instantiated the object representing the 
top quark. However, since the top quark is not a self-conjugate particle, we 
still need to implement an object representing the top antiquark. We could 
proceed in a similar way as in the example above, but the Particle class has a 
built-in method, denoted anti(), instantiating the antiparticle object directly 
from the corresponding particle object. In the example of the top quark, the 
instruction 

t tilde = t.antiO 

instantiates a Particle object called t tilde which is identical to the 

object t previously defined, but with the attributes name (texname) and 
antiname (antitexname) interchanged. In addition, all the quantum numbers, 
including the electric charge (charge) and the color representation (color), 
are set to opposite values. 

2. 3 Implementation of the parameters of a model 

Parameters of a model, like masses, coupling constants, etc., are defined in 
an UFO model as instances of the Parameter class (itself defined in the file 
object_library .py) in the file parameters .py. All the parameters used in 
a model implementation are either external (or equivalently independent) pa- 
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Table [2fc Attributes of the particle class 


pdg_code 


An integer corresponding the identification number related 
to the PDG numbering scheme [27j. 


name 


A string specifying the name of the particle. 


antiname 


A string specifying the name of the antiparticle. If the par- 
ticle is self-conjugate, antiname must be identical to name. 


spin 


An integer corresponding to the spin of the particle in the 
form 2s + 1. By convention, the spin of a ghost field (anti- 
commuting scalar field) is -1. 


color 


An integer corresponding to the dimension of the color rep- 
resentation of the particle (1, ±3, ±6, 8). 


mass 


A Parameter object corresponding to the mass of the par- 
ticle. If the particle is massless, the value must be set to 
Par am. ZERO. 


width 


A Parameter object corresponding to the width of the parti- 
cle. If the width is zero, the value must be set to Par am . ZERO. 


texname 


A T^X string representing the particle name. 


antitexname 


A TgX string representing the antiparticle name. 


charge 


A rational number equal to the electric charge of the particle. 


Optional attributes 


goldstone 


A boolean, tagging a scalar field as a Goldstone boson (true) 
or not (false). The default value is false. 


propagating 


A boolean, tagging the corresponding particle as auxiliary 
and non-propagating (false) field or as a physical field 
(true). The default value is true. 


line 


A string representing how the propagator of the particle 
should be drawn in a Feynman diagram. The possible val- 
ues are 'dashed', 'dotted', 'straight', 'wavy', 'curly', 
'scurly','swavy' and 'double'. The default value is cho- 
sen according to the spin and color representation of the 
particle. 
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rameters or internal (or equivalently dependent) parameters. The user must 
provide as an input the numerical value of the external parameters (e.g., 
a s = 0.118), while the internal parameters are related to other (external 
and/or internal) parameters via algebraic relations (e.g., g s = y/4ira s ). Since 
internal and external parameters belong to the same generic class Parameter, 
their declaration is very similar. We will give an example for each case sepa- 
rately in order to emphasize the main differences and features. The list of all 
the possible attributes for the Parameter class is summarized in Table |3j 

We start with external parameters. In the UFO format, the external param- 
eters are all taken to be real and the type attribute of the Parameter class 
must be set to the value 'real'. Therefore, complex numbers will have to be 
split into their real and imaginary parts. As an example, the declaration of 
the external parameter a s reads 

aS = Parameter (name = ' aS ; , 

nature = ' external ' , 
type = 'real ' , 
value = 0.118, 
texname = ' \\alpha_s' , 
lhablock = 'SMINPUTS', 
lhacode = [ 3 ] 
) 

The attributes of the Parameter class are all mandatory and contain the name 
of the parameter (name), its nature (nature) which is external and the value 
of the parameter (value). Since any external parameter is a real number, the 
value must be a real floating point number. The last two arguments, lhablock 
and lhacode, refer to the Les Houches-like format for the input parameters 
which is followed by the UFO. This is a generalization to any model of the 
original Supersymmetry Les Houches Accord [25]T2§] . All the model parameters 
are grouped into blocks, each line of a block containing a counter (a sequence 
of integers) associated with a given parameter name and its corresponding 
numerical value. The attribute lhablock of the Parameter object directly 
refers to the name of the block in which the considered parameter is stored, 
whilst the attribute lhacode is a list of integers referring to the counter. 

An additional function related to the Les Houches format is included in the file 
write_param_card.py. The class ParamCardWriter can be called from within 
another Python module by issuing the instruction 

ParamCardWriter ( ' ./param_card.dat ) , qnumbers=True) 

and outputs a parameter file named param_card.dat which contains all the 
external parameters defined in the model, grouped into blocks and counters 
according to their lhablock and lhacode attributes. The first argument in 
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the function above refers to the location of the output file, whereas the second 
argument specifies whether or not the QNUMBERS blocks [30] should be included 
in the output. In addition, if the second argument is set to True, the full set of 
masses and widths, even if they are dependent parameters, are written to file. 
In the example of aS presented above, the corresponding entry in the output 
file would read 

Block SMINPUTS 

3 1.18000e-01 # aS 

Let us also note that the file write_param_card.py can be directly used from 
the command line by issuing the instruction 

$> python . /write_param_card.py 

As a result, an output file named param_card.dat is created and contains the 
numerical values of all the external parameters. A snapshot of this parameter 
file for a more complete model reads 

################################### 

## INFORMATION FOR SMINPUTS 
################################### 

Block SMINPUTS 

1 1.325070e+02 # aEWMl 

2 1.166390e-05 # Gf 

3 1.180000e-01 # aS 

################################### 

## INFORMATION FOR YUKAWA 
################################### 

Block YUKAWA 

5 4.200000e+00 # ymb 

6 1.645000e+02 # ymt 
15 1.777000e+00 # ymtau 

The definition of internal parameters follows the same lines as for the ex- 
ternal parameters, with the only differences that the lhablock and lhacode 
attributes are not available and that the value argument now contains an 
algebraic expression relating the parameter to other external or internal pa- 
rameters. As a simple example, consider the external parameter aS (a s ) and 
the internal parameter G (g s = ^Aira s ). The implementation of G reads, 

G = Parameter (name = 'G', 

nature = ' internal ' , 
type = 'real' , 

value = , cmath.sqrt(4 * cmath.pi * aS) ' , 
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Table [3} Parameter class attributes 


nature 


A string, either ' external ' or 'internal 1 , specifying 
whether a given parameter is considered as a dependent or 
independent parameter. 


name 


A string, specifying the name of the parameter. 


type 


A string, either 'real' or 'complex', specifying whether a 
given parameter is a real or a complex number. We remind 
that following the UFO synthax, external parameters must 
be real numbers. 


value 


For external parameters, this attribute is a single real 
floating-point number. For internal parameters, it consists 
of a string representing the analytic expression relating the 
considered parameter to other external and/or internal pa- 
rameters, following a valid Python syntax. 


texname 


A TpjX string representing the parameter name in Tpfi. for- 
mat. 


Attributes 


specific to external parameters 


lhablock 


A string containing the name of the block which the param- 
eter is assigned to, following a Les Houches-like format. 


lhacode 


A list of integers giving the position of the considered pa- 
rameter inside a given lhablock, i.e., the counter associated 
with the parameter, following a Les Houches-like format. 



texname = 'G' 
) 

Unlike the case of external parameters, the value attribute is a string rep- 
resenting a valid algebraic Python expression. Moreover, it is mandatory 
that every internal parameter depends only on other parameters which have 
already been declared. Returning to our example, the external parameter 
aS must hence be denned before the internal parameter G inside the file 
parameters .py. Note that masses and widths are considered to be param- 
eters of the model (either internal or external), and must thus be declared as 
such in parameters .py. 

Let us conclude this section by mentioning that most matrix-element gener- 
ators have information on the Standard Model input parameters hard-coded. 
This allows, among others, for a correct handling of the running of the strong 
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coupling constant. Therefore, the Standard Model parameters in an UFO 
model must be correctly identified, following the same notations and con- 
ventions as for the implementation of a model in Feyn Rules [2"U] . 



2.4 Implementation of the interactions of the model 



The vertices corresponding to the interactions included in a model are defined 
in the file vertices. py using the Vertex class. Let us consider a set of n 
particles {(fii iai }, with spin indice^J] and color indices {a^}. A generic n- 
point vertex coupling these fields can be written as a tensor in the color 
spin spac 



(2.1) 



where the variables pi denote the particle momenta, Gij the couplings, and 



the quantities Cf 1 ™"" and "(pi, • • • ,p n ) denote tensors in color and spin 
space, respectively. Since several vertices may share the same spin and/or color 
tensors, the latter act as a 'basis' for the vertices of the model, the couplings 
being the 'coordinates' in that basis. As an example, the well-known four-gluon 
vertex, 



ig2 jaia 2 b jba^a^ ^/LtijU4^2/i3 



-\- ig 2 j a l°-4.b jba 2 a :j ^A 1 iA»3 T1 A 1 2A t 4 _ ^A t iA t 2 T1 A t 3A»4 N 



(2.2) 



is written in Eq. (12. ip as 



(f aia2b f 



60304 
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X 
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^MlM4^M2M3 



^A t lA t 3^M2A t 4 



^1/^3^2/^4 



^MlM2^M3M4 



? yA»lM2^A t 3A'4 



(2.3) 



The UFO format for vertices mimics exactly this structure. As an example, 
the implementation of the vertex in Eq. (12. 3 p into an UFO model reads 



V_l = Vertex(name = 'V_l', 

particles = [ P.G, P.G, P.G, P.G ], 
color = [ 'f (1,2, -l)*f (-1,3,4) ' , 



1 The terminology spin indices refers to both Lorentz and Dirac indices. 

2 The case of non-strongly interacting particles corresponds to a tensor in color 
space equal to unity. 
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Table [4} Vertex class attributes 


name 


A string specifying the name tag of the vertex. 


particles 


A list of Particle objects containing the set of particles en- 
tering into the vertex. By convention, all particles are con- 
sidered outgoing. 


color 


A list of strings representing the color tensors associated 
with the vertex, written as a polynomial combination of the 
elementary tensors given in Table [5j 


lorentz 


A list of Lorentz objects representing the spin tensors asso- 
ciated with the vertex. 


couplings 


A list of Coupling objects associated with the decomposition 
of the vertex in the color (g) spin space. 



'f (1,3, -l)*f (-1,2,4)', 
'f (1,4, -l)*f (-1,2,3)' ], 

lorentz = [ L.VVVV1, L.VVVV2, L.VVVV3 ], 

couplings = {(0,0) :C.GC_1, 

(1.1) :C.GC_1, 

(2.2) :C.GC_1} 

) 

The Vertex class is probably one of the most important features of the UFO 
format, since the vertices associated with a Lagrangian are at the heart of 
every implementation of a BSM model into a matrix-element generator. It 
requires five arguments, which are summarized in Table HI First, each vertex 
is identified by an identification tag, its name. Next, the attribute particles 
contains the list of all Particle objects entering the considered vertex (by 
convention, all particles are considered outgoing). Since these objects are de- 
fined in the file particles .py, it is necessary to issue at the beginning of the 
file vertices. py the command 

import particles as P 

and a particle object G is now referred to as P.G. The attributes color and 
lorentz contain two lists with the color and Lorentz tensors associated with 
the vertex, i.e., the quantities CI 1 '"" 171 and Lj 1 '" n {jp\, . . . ,p n ) appearing in Eq. 
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xaDie lot jjjienienrary coior 


tensors 


Trivial tensor (for non-colored particles) 


1 


Kronecker delta 5- l2 i 1 


laeiiri uy \± , Z) 


Fundamental representation matrices (J 101 )-' 3 j 2 


l (.1,2,3; 


Structure constants f aia2a ^ 


±(.1,2,3; 


Symmetric tensor d a ^ a ^ a ^ 




Fundamental Levi-Civita tensor £i 1 i 2 i 3 


hps lion u ,Z,6) 


Antifundamental Levi-Civita tensor e* 1 * 2 * 3 


EpsilonBar(l ,2,3) 


Sextet representation matrices (Tg 1 ) a2 


T6(l,2,3) 


Sextet Clebsch-Gordan coefficient {K^) l2 ^ z ai 


K6(l,2,3) 


Antisextet Clebsch-Gordan coefficient {Ko) ai i 2 j 3 K6Bar (1,2,3) 



(12. ID . and are represented inside an UFO module as, 

^aiflfloaat^ ^080804 jG » iaa a8a«) ^ ['f (1,2,-1) * f(-l,3,4)', ... ] , 

( L MiM2M3/x4 )L /xiM2M3M4 )L mM2/x3/M) ^ [ l . VWV1 , L . VVVV2 , L.VVVV3 ] . 

Each color tensor is given as a string representing a polynomial combination 
of elementary color tensors, whose arguments are integer numbers referring to 
the position of the particle in the list particle. If two indices are contracted, 
they are represented by a negative integer. The set of all the elementary color 
tensors currently included in the UFO format, together with the corresponding 
Python syntax, is given in Table [5j Using these conventions, the color tensors 
related to the four gluon vertex are given by 

ja ia2 b jba s a 4 ^ > f ( 1 , 2 , "1 ) * f ("1 , 3 , 4) ' , 
ja 3 a 2 b jba 2ai ^ > f ( 1 , 3 , "1 ) * f ("1 , 2 , 4) ' , 
ja iai b jba 2 a z ^ > f ( 1 , 4 , "1 ) * f ("1 , 2 , 3) ' . 

Since the list of color tensors associated with a vertex is a mandatory argument 
of the Vertex object, we define the trivial color structure associated with an 
interaction among non-colored particles as the color tensor ' 1 ' . 

Spin structures such as those appearing in the vertex decompositions in color 
<S> spin space are implemented as instances of the class Lorentz. All the struc- 
tures necessary for the whole model are declared in the lorentz. py file and 
we must hence issue at the beginning of the file vertex. py the instruction 
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Table [6fc Elementary Lorentz structures 



Charge conjugation matrix: 


C(l,2) 


Epsilon matrix: e^ 2 ^ 4 


Epsilon(l,2,3,4) 


Dirac matrices: (7 w )i 2 i 3 


Gamma(l, 2, 3) 


Fifth Dirac matrix: (7 5 )i 1 j 2 


Gamma5(l,2) 


(Spinorial) Kronecker delta: 5^ 


Identity (1 ,2) 


Minkowski metric: ^ 1/12 


Metric(l ,2) 


Momentum of the N th particle: 


P(l.N) 


Right-handed chiral projector: ( 1 ^ 2 75 ) 


ProjP(l,2) 


Left-handed chiral projector ( 1 ^ 75 ) 


ProjM(l,2) 


Sigma matrices: (c^ 1 ^ 2 )^^ 


Sigma(l,2,3,4) 



import lorentz as L 

Hence, the Lorentz objects used in vertex. py, declared in the lorentz. py 
Python module, are preceded by the prefix L. As illustrated in the example 
of the four-gluon vertex, the lorentz attribute of the Vertex class contains 
the list of the relevant structures. A Lorentz object is instantiated as 

FFV1 = Lorentz (name = 'FFV1', 

spins = [2, 2, 3 ] , 
structure = 'Gamma(3,2, 1) ') 

All attributes are mandatory. While the attribute name is denned in the usual 
way, the attribute spins contains the list of the values of the spins, written as 
(2s + 1), of the particles entering the vertex. The last argument, structure, 
gives the analytical formula of the Lorentz structure as a string. The conven- 
tions for the spin indices is similar to the convention for the color indices: a 
positive integer i points to the entry i in the list spins while negative inte- 
gers are contracted indices. By default, all the Lorentz indices are supposed 
to be upper indices, and repeated Lorentz indices are contracted using the 
Minkowski metric. The list of all objects that can be used to define a Lorentz 
structure is given in Table [6j 

For a given vertex, the quantities appearing in Eq. (12. ip are the 'coordi- 
nates' corresponding to the decomposition of a vertex into the color ® spin 
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basis. The couplings attribute of the Vertex class contains hence a PYTHON 
dictionary relating the coordinate to a Coupling object, declared in the 
file couplings .py, 

dj <r± (i,j) :C.GC_1 , 

By convention, only non-vanishing coordinates Gij are included in this dictio- 
nary. Moreover, the Coupling objects must be imported at the beginning of 
the vertices. py file through the command 

import couplings as C 

The declaration of the Coupling objects in the file couplings .py is similar to 
the one of internal parameters. Going back to the example of the four-gluon 
vertex in Eq. (12. 3p . the coupling GC_1 is defined by 

GC_1 = CouplingCname = 'GC_1', 

value = ' complex (0, 1)*G**2' , 

order = {'QCD' :2} 

) 

The attribute value is a string giving the algebraic expression of the cou- 
pling in terms of internal and/or external parameters. The last attribute of a 
Coupling object, order, is a PYTHON dictionary where the key for each entry 
is a string and the value a non-negative integer. In the example above, this 
means that the four-gluon vertex is proportional to two powers of the strong 
coupling. This feature allows certain matrix-element generators to generate 
only subclasses of Feynman diagrams at runtime. This subclass is determined 
by giving an upper limit for a given interaction type, specified by the key in 
the dictionary order. This concept, together with its implementation into the 
UFO format, is explained in the next section. 

2. 5 Controlling various types of couplings in a perturbative expansion 

In this section we discuss how to control the different types of expansion 
parameters that might appear in a perturbative expansion. To illustrate this 
concept, let us consider the production of a weak boson in association with jets 
at a hadron collider, e.g., pp — > Z + 4 jets. This process is dominated by QCD 
production, while diagrams involving off-shell weak boson exchanges are highly 
suppressed. In order to speed up the event generation for this process, it is thus 
desirable to focus exclusively on the strong production of the additional four 
jets, neglecting all Feynman diagrams with weak boson exchanges. In other 
words, we would like to select the subset of all the diagrams contributing to 
the process pp — >■ Z + 4 jets that involve at most one electroweak vertex, i.e., 
at most one power of the electromagnetic coupling constant e. 
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This can be achieved using tags that allow to count the number of couplings of 
a given type present in a diagram. In the previous section, we have introduced 
the order attribute of the Coupling class. As examples, the order of g 2 
was hence defined as {'QCD' , 2}, whilst the one of e 2 reads {'QED' :2}. In 
the case of the generation of the Feynman diagrams associated to the pp — > 
Z + 4 jets process, the coupling order feature allows to restrict the number of 
couplings of type QED to be at most one, neglecting in this way the electroweak 
production of any additional je For certain models, it can be useful to 
specify a default behavior for some types of coupling orders. This can be done 
using the CouplingOrder class, which we describe in the rest of this section. 

Coupling orders are instances of the class CouplingOrder and are instantiated 
in the file coupling_orders .py. As a first simple examples, let us consider 
the coupling orders QCD and QED, corresponding to the coupling constants g s 
and e, respectively. The definitions in coupling_orders .py read 

QCD = CouplingOrder (name = 'QCD', 

expansion_order = 99, 

hierarchy = 1 

) 

QED = CouplingOrder (name = 'QED', 

expansion_order = 99, 

hierarchy = 2 

) 

The class CouplingOrder has two mandatory attributes, apart from the ubiq- 
uitous name attribute. First, the attribute expansion_order is an integer spec- 
ifying the maximal number of couplings of this type that should be included in 
a given process. The default value is 99, indicating that any number is allowed. 
The second attribute, hierarchy, is an integer that allows one to classify dif- 
ferent types of interactions according to their relative strength. In the above 
example, we have QCD. hierarchy = 1 and QED .hierarchy = 2, reflecting the 
fact that g\ is of the same order of magnitude as e 2 . The CouplingOrder ob- 
jects then allow certain matrix-element generators to define a default behavior 
for the maximal number of couplings of a given type that can appear in a di- 
agram, based on the upper bound set by expansion_order and the relative 
strength among the various couplings. 



3 We stress that coupling orders are a property of the matrix-element generators, 
i.e., the matrix-element generator in question needs to support this feature to use 
it. 
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3 The FeynRules UFO interface 



Even though it is possible to implement a model into the UFO format by hand, 
this procedure can be a tedious and error-prone task, because all the vertices 
need to be entered one at the time. In order to alleviate this problem, we have 
implemented an interface into FeynRules that allows one to export a given 
model directly in the UFO format. The FeynRules model contains, on the 
one hand, basic model information (such as the particle content or the pa- 
rameters of the model) which is implemented as described in Refs. [19f20f22] . 
In particular, a new feature of the FeynRules model files allows to specify the 
hierarchy between the different types of couplings and the limit up to which 
they should appear in the perturbative expansion (see Section 12. 5p . This 
is achieved by including the global variables M$InteractionOrderHierarchy 
and M$InteractionOrderLimit directly into the FeynRules model fildjj. 
Considering the example of the types of couplings QED and QCD presented 
in Section 12. 5\ the FeynRules model implementation includes then the def- 
inition 

M$InteractionOrderHierarchy = { 
{QCD, 1}, 
{QED, 2} 

} 

M$InteractionOrderLimit = { 
{QCD, 99}, 
{QED, 99} 

} 

Note that this new feature is optional for each type of coupling. If a given 
type if not represented in one of the two lists, the default values assigned will 
be 1 for the hierarchy and 99 for the expansion_order. 

The FeynRules UFO interface can be called in exactly the same way as all 
the other FeynRules interfaces, 

WriteUFO [ C\, ■ ■ ■ , options ] 

where C\, . . . denote the Lagrangians of the model, and options denotes a 
set of options supported by the interface. The interface shares all the options 
of the function FeynmanRules [ ] , plus some additional options summarized 
in Table [7J When this command is issued, FeynRules internally calls the 
function FeynmanRules [ ] to compute all the vertices associated with the 

4 InteractionOrder is the FeynRules equivalent to the order attribute of the 
UFO Coupling object presented in Section [2^1 
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Table Additional options of the function WriteUFO 


Input 


A list of vertices computed previously and to be included 




into tne Ul'U output. 


Output 


A string, the name of the output directory. The default is 




the value of the FeynRules variables M$ModelName with 




_UF0 appended. 


DialogBox 


If Of f , no dialog boxes open up when running the interface. 




The default is On. 



Lagrangians Li. After the complete list of Feynman rules has been obtained, 
the vertices are decomposed into a color ® spin basis[3 according to Eq. ( 12. ip . 
and the different Lorentz and Coupling objects are identified. At the end of 
the procedure, all the information about the model is written to files according 
to the format presented in Section [2J and saved in a directory called *_UF0, 
where * denotes the name of the model. 

Note that there is a crucial difference between the UFO interface and the other 
existing interfaces included in the FeynRules package. While all other in- 
terfaces select the subset of vertices that are supported by the matrix-element 
generators (in general, this subset consists more or less into renormalizable 
operators) while rejecting all other vertices, the UFO interface is completely 
agnostic of the matrix-element generator, and hence does not make any as- 
sumptions on whether a given generator accepts a certain vertex structure. 
The UFO output will hence always contain all the vertices of the model, and 
it is then up to the matrix-element generator to assure that only allowed 
vertices are processed. 



4 The UFO format beyond tree level 

During the last five years, a lot of progress has been made in the automation 
of the computation of next-to-leading order matrix elements, both regarding 
the generation of the real corrections with the appropriate subtraction terms 
[31f32f33f34ll35ll36] . and the development of algorithms for calculating loop 
amplitudes numerically [37 38.39 4 0|I4 l|!42j . 

Although currently the focus of the UFO is to provide a common input 
for tree-level Monte Carlo programs, the format is by no means restricted 

5 Note that this decomposition might not be unique. 
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to tree-level generators only. Hence, the one-loop matrix-element generator 
GoSam [24|25P26] contains an interface to the UFO format, where the infor- 
mation from the Python module described in Section [2] is translated into 
a model definition for the QGraf package [43] together with a Form [44] 
module substituting the expressions from the Feynman rules. This setup has 
been successfully applied to simple one-loop calculations in the Minimal Su- 
persymmetric Standard Model, where the renormalization can still be worked 
out by hand. For more involved computations, however, one would like to 
automate not only the calculation of the matrix elements but also the deriva- 
tion of the counterterms associated with a given renormalization procedure. 
Although FeynRules in its current version does not yet support the calcula- 
tion of renormalization constants and counterterms, we propose in this section 
a generic prescription for their inclusion in the UFO format. 

Assuming a multiplicative renormalization prescription, the relation between 
bare and renormalized quantities is given by mo = Z m m r = (1 + 5Z m )m r , 

1 /2 1 

where m represents a generic parameter, and by \l>o = Z^ ^> r = (1 + ^5Zq,)^ r 
for the fields. The general case of propagator mixing allows the last equation 
to take a matrix form. Furthermore, it is assumed that the ultraviolet di- 
vergences have been regularized dimensionally, the renormalization constants 
being thus expressed as Laurent series in e = (4 — D)/2 where D is the number 
of space-time dimensions. Taking into account that the format should not be 
restricted to one type of perturbative corrections but should be extendable to 
any ol^ x o^ w order of the perturbative expansion, we can make the ansatz 

00 n> ni rv n2 00 

SZ- = V s EW V z ip) e p (4 1) 

ni,n2=l \ / p=— oo 

where, in general, only a small subset of the coefficients z^ is non-zero. 
To include the renormalization constants associated with a parameter, we 
propose to add an attribute to the Parameter class denoted counterterm. 
Taking the example of the strong coupling constant introduced in Section 12. 3[ 
G, its definition is augmented by 

G. counterterm = { (1,0): {-1: ' 2 . /3*NF*TF-11 . /6*CA' } } 

in order to include the QCD one-loop effects on the strong coupling constant. 
The renormalization constant is represented by a Python dictionary where 
the keys are the pairs (77,1,712) introduced in Eq. (14. ip and the values are the 
Laurent series in e. The latter are represented by dictionaries with the powers 
of e as keys and strings representing Python expressions as values. Let us 
note that the symbols NF, TF and CA which have been introduced must be 
either replaced by their proper values or be defined as model parameters. For 
models containing more than two coupling constants, the pairs (nx,^) are 
replaced by the corresponding rz-tuples. Similarly, wave function renormaliza- 
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tion constantg_J are included in the counterterm attribute which is added 
to the Particle class. It contains the object 5Z^, implemented following a 
structure identical to the one described for the Parameter class. 

In addition to the renormalization constants, one also needs analytical ex- 
pressions for the counterterms. In general, they can be described as vertices, 
starting from two-point vertices for the propagator counterterms, which are 
included in the files ctvertices .py and ctcouplings .py. Analogously, the 
initialization file __init__.py contains, in addition to the lists described in the 
previous section, the lists all_ctvertices and all_ctcouplings. Similarly 
to Section |2.4[ the file ctvertices .py contains all the counterterm vertices 
represented by objects of the Vertex class, and the related couplings are in- 
cluded in the file ctcouplings .py. These couplings reflect the nature of the 
renormalization constants as Laurent expansion in e. Using the generic struc- 
ture for vertices presented in Eq. (]2.1]) "^1 we can write a counterterm coupling 
as 

oo ^,ni„, n 2 oo 

G- = a {0) V s EW V c {p) e p (42) 

n\,n2=X \ ) p=—oo 

This ansatz allows for some freedom with respect to numeric factors that can 
be part of either gff or Cjj >niin2 . However, the power of the coupling constants 

in gff must correspond to the one included in the associated tree level vertex. 
Hence, the counterterm coupling can be easily declared using the Coupling 
class, 

GCT_1 = Coupling(name = 'GCT_1', 

value = ' complex (0, 1)*G**2' , 

counterterm = {(1,0): {-1 : G. counterterm}}, 

order = {'QCD' :2} 

) 

The prefactor is stored in the value attribute whereas all relative cor- 
rections Cjj mn2 are mapped to the attribute counterterm, using the same 
philosophy as in the case of the classes Parameter and Particle. Finally, the 
attribute order reflects the interaction order of gj-j and does not take into 
account the additional powers of coupling constants coming from the sum over 
rii and n 2 . 

The amendments described in this section transmit all information necessary 
for an efficient computation of ultraviolet counterterms by a matrix-element 
generator. Furthermore, the same approach could be used in order to include 



6 Mixing of on-shell particles is assumed to be zero. However, in propagators, mixing 
is realized through two-point vertices. 

The basis in the color ® spin space associated to a counterterm vertex might be 
different from the corresponding tree-level one. 
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other counterterm-like objects, such as the rational R2 terms [45|46f47|H8] in 
the OPP approach [35150] . 



5 An example 



An UFO model contains the full set of vertices of a model, i.e., all the Lorentz 
and color structures appearing in all the vertices together with their coeffi- 
cients. Consequently, it is also suited for models with Lorentz structures that 
are not SM-like, a characteristic shared by all models with higher-dimensional 
operators. In the following, we illustrate the UFO format on the example of 
the Strongly Interacting Light Higgs (SILH) model [51]. The SILH model is 
an effective theory describing the interactions of the Higgs boson considering 
it as the Goldstone boson linked to a new strongly interacting sector. Since it 
is already implemented in FeynRules (2U], this model can easily be exported 
to the Monte Carlo tools via the corresponding FeynRules interfaces. 

The particle content of the SILH model is the same as in the SM. The par- 
ticularities of the model come solely from the new interactions induced by 
dimension-six operators involving SM fields. In this short example, we focus 
on the decay of the Higgs boson H into two H^-bosons. The non-SM part of 
the SILH Lagrangian affecting this decay rate reads 



^ = {pH) d, {rfH) + ^ (HW&H) (D»W^ 



+ ^f 2 {D^H)^\D^H)W; v (5.1) 

where / is the suppression scale for the new operators, g and g p are the cou- 
pling constants of the weak and the new strong interaction, respectively, and 
ch, cw and chw are free coefficients. In the expression above, we have intro- 
duced the covariant derivative (taken in the appropriate representation), 
the VF-boson field strength tensor W^ Vl and the Pauli matrices <r\ The effec- 
tive Lagrangian has been obtained after an expansion in 1// up to 0(1/ f 2 ). 
Hence, the HWW vertex reads now 



? 1 



P\"$L + PTpT - {Pl-P2 + Pl-Ps) Vl* 



2,M3 



(P2-P2+P3-P-i)V^2, 



I'-'. 



P2 P2 



32n 2 v 



(5-2) 



where £ = , v being the vacuum expectation value of the neutral component 
of the Higgs doublet, and pi are the momenta of the interacting particles. 
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After an UFO implementation of the model via the corresponding FeynRules 
interface has been obtained, this vertex appears in vertices. py as 

V_22 = Vertex (name = 'V_22> , 

particles = [ P.W minus , P.W plus , P.H ], 

color = [ '1' ] , 

lorentz = [ L.WS1, L.VVS5, L.VVS8 ], 
couplings = {(0,1) :C.GC_56, (0,2) :C.GC_59, 
(0,0) : [ C.GC.30, C.GC.68 ]}) . 

The color tensor is trivial since all particles are color singlets. On the contrary, 
the spin structure is more complicated because of the non-trivial tree-level 
Lorentz structures of Eq. fl5.2p . As an example, the VVS8 spin tensor is defined 
in the file lorentz . py as 

VVS8 = Lorentz (name = ' WS8 ' , 

spins = [3, 3, 1 ] , 

structure = 'P(l ,3) *P(2 , 1) + P(l ,2)*P(2,3) 

- P(-l,l)*P(-l,3)*Metric(l,2) 

- P(-l,2)*P(-l,3)*Metric(l,2) ') 

The product of VVS8 and GC_59 corresponds to the second term of Eq. (15. 2p . 
The coupling order of the coupling is given by NP=1, indicating that it contains 
one power of £. It is important to note that VVS1, the Lorentz structure of 
the first term in Eq. (15.21) is associated with two coefficients, split according to 
their coupling order. In particular, GC_30 is the SM part and corresponds to 
the order QED=1, while GC_68 is the new physics contribution proportional to 
ch and of order NP=1. Interferences between SM and new physics operators can 
be extracted from the interaction order of the vertex. Indeed, due to our choice 
for the Ci coefficients, the new physics pieces of the vertex have an interaction 
order equal to NP=1 and QED=0. Therefore, the interference is obtained by 
computing the difference between all the contributions (NP=1 QED=1) and the 
pure SM (NP=0 QED=1) and SILH (NP=1 QED=0) ones. 

The Lagrangian of Eq. (15. ip is truncated at order 0(1/ f 2 ), or equivalently at 
order 0(£). Computation of matrix elements at higher order in £ would hence 
not be reliable without adding the corresponding terms in the expansion of 
the Lagrangian. For instance, the production of a Higgs-boson pair by weak 
boson fusion involves a diagram containing two vertices with order NP=1, as 
presented in Fig. [TJ but also an additional diagram related to the expansion 
of the Lagrangian at order 0(C, 2 ), which is absent from our SILH model im- 
plementation. To prevent the user from such issues, the model builder should 
warn him that (9(£ n ) amplitudes, with n > 2, cannot be in general computed 
using the implemented Lagrangian, and that the NP order should be at most 
equal to one. This restriction is easily included in the UFO model through to 
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Fig. 1. Feynman diagram contributing to W + W~ ->■ HH at 0(£ 2 ). The shaded 
boxes represents the 0(£) part of the HWW vertex in Eq. (|5.2|) . 




boson into two W bosons in the SILH model for g p = 1, / = 1 TeV, f = 0.060623, 
Cf/ = 4, = 2 and c#ty = 800. Only the interference terms between SM and 
diagrams involving the new operators are taken into account in Tsilh ( see Eq. 
(6.6) of Ref. [20J and references therein). 



the expansion_order argument of the CouplingOrder object 

NP = CouplingOrder (name = 'NP', 

expansion_order = 1, 

hierarchy = 2 

) 

The hierarchy argument being set to 2 ensures that the new physics contri- 
butions are not removed by default in the weak processes. 

We choose to validate our UFO model by using the computation tools Mad- 
Graph version 5 [13], which thanks to the Aloha module [52], allows for 
a full support of the higher dimensional operators. We have computed the 
Higgs partial decay width into a IV-boson pair, using a very large value for 
chw m order to render the associated new physics contribution dominant 
and to subsequently test the treatment of the higher-dimensional operators 
by MadGraph. Moreover, this contribution is not proportional to the SM 
result, contrary to the others. In Fig. [2J we confront the results to hand-made 
analytical calculations and found perfect agreement. 
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6 Conclusion 



In this paper, we have presented a new model format for matrix-element gen- 
erators, the Universal FeynRules Output (UFO) format. While most of the 
present generators have implicit assumptions on the color and/or Lorentz 
structures appearing in the different interaction vertices of a given model, 
the UFO format has been designed to go beyond these constraints, by being 
agnostic of any, even unforeseen, restrictions. Indeed, unlike the more tradi- 
tional table-based model formats (as used by many Monte Carlo codes), the 
UFO represents all the information about a model terms of abstract Python 
classes that can accommodate any (reasonable) particle physics model. As an 
example, despite the fact that so far only color singlet, triplet, sextet and octet 
particles have been implemented into the UFO format, the extension to more 
exotic representations of the QCD gauge group is in principle straightforward, 
without requiring any change to the UFO format itself. A similar change would 
be very hard to perform in some of the existing table-based model formats. 
Finally, we emphasize that the format gives a full support to Les Houches 
accord conventions for model parameters and we also illustrate how it could 
be extented in the context of the next-to-leading order tools, including, e.g., 
counterterms and the so-called R2 terms. Presently, the UFO format is already 
used by the MadGraph version 5 and GoSam generators and will be used 
in a near future by HERWIG++. 
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